tools: libxl: hide selection of device-model by default.

tools: libxl: hide selection of device-model by default.

This should never have been exposed to users as something they are
required to think about, unless they want to.

At the libxl API level:
      * Add libxl_device_model_info.device_model_version allowing the
        user to say which qemu version (e.g. old qemu-xen or qemu
        upstream) they want for a domain.
      * Add libxl_device_model_info.device_model_stubdomain allowing
        the user to select stub or non-stub device model
      * Default both the device_model field to NULL and DTRT when
        building a domain with that value in those fields, but still
        allow libxl users to specify something explicit if they want.
      * Note that libxl_device_model_info.device_model, if specified,
        must now be a complete path.

At the xl level:
      * Support a new "device_model_version" option which sets the new
        libxl_device_model_info.device_model_version field. This
        option is mandatory if device_model_override is used.
      * Support a new "device_model_stubdomain_override" option which
        allows the user to request stubdomain if desired.
      * WARN if an HVM guest cfg uses the "device_model" config
        option, and direct users to the "device_model_override" option
        if they really do not want the default. If the "device_model"
        directive contains "stubdom-db" then direct users to the
        "device_model_stubdomain_override" directive.

The default qemu remains the existing qemu-xen based qemu-dm and
stubdomain defaults to off. I chose the name "qemu-xen traditional" to
refer to the existing Xen fork of qemu and simply "qemu-xen" to refer to
the new device model based on qemu upstream.

I suspect that the vast majority of users only have these config
options because they've copied them from somewhere and they normally
have no interest in which device model is used. Renaming the fields
and warning when they are used makes these decisions internal. This
will allow us to make decisions at a platform level regarding the
preferred hvmloader, device model, stub domain etc without requiring
everyone to change their configuration files.

Adding a device model version to the API is intended to make it easy
for users to select what they need without having to know about the
paths to specific binaries etc. Most importantly it gets rid of the
parsing of the output of qemu -h...

It's not clear where upstream qemu will eventually be installed, I
went with /usr/bin/qemu for now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>